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1.  Summary 

This  is  the  Description  of  the  Concurrent  Engineering  (CE)  Technology  for  the  Manufacturing 
Optimization  (MO)  System.  The  purpose  of  the  Manufacturing  Optimization  (MO)  system  is  to  enable  each 
manufacturing  specialist  to  participate  in  the  product^rocess  development  activity  concurrently.  The  system  will 
consist  of  a  set  of  tools  to  model  the  manufacturing  processes  and  centralize  the  various  process  tradeoffs.  This 
report  addresses  “user  hardening”  of  existing  concurrent  engineering  technology  by  applying  existing  DICE 
tools  to  other  technology  areas,  in  this  case  Design  for  Manufacturing  and  Assembly  (DFMA).  The  DICE  tools 
proposed  for  use  under  the  MO  program  included  ROSE  Database  Management  System  (DBMS),  Consu-ainis 
Management  System  (CMS),  and  the  Requirements  Manager  (RM).  The  Project  Coordination  Board  (PCB) 
and  Communications  Manager  (CM)  were  added  to  the  scope  of  the  evaluation  because  the  September  release  of 
the  CMS  will  be  integrated  with  the  PCB/CM. 

Raytheon  proposed  to  use  ROSE  to  store  and  manage  the  process  models  and  analysis  data  for  the  MO 
system.  As  part  of  the  evaluation  process  of  ROSE,  we  developed  a  set  of  test  cases  to  demonstrate  the 
applicability  of  the  ROSE  DBMS  to  adequately  model  the  manufacturing  process  models  and  analysis  data. 
Based  on  the  results  of  our  sample  test  case,  we  believe  that  the  ROSE  DBMS  is  able  to  handle  the  various 
types  of  manufacturing  process  model  and  analysis  data  required  in  the  MO  environment.  We  recommended  the 
continued  use  of  the  ROSE  DBMS  as  the  repository  for  all  the  process  data  files  for  the  manufacturing 
processes  and  operations,  as  well  as,  the  various  analysis  results  for  the  MO  system.  To  better  understand  the 
more  advanced  features  of  ROSE,  attending  the  three  day  training  session  conducted  by  Step  Tools  Inc.  is 
recommended. 

Raytheon  proposed  to  use  the  CMS  to  provide  a  mechanism  for  constraining  the  product  design  to  process 
capabilities.  Since  the  pilot  site  version  of  the  CMS  software  was  unavailable  for  testing,  Raytheon  planned  a 
trip  to  CERC  for  a  demonstration  of  the  CMS  and  a  meeting  with  the  developers.  Based  on  the  CERC  visit,  it 
was  determined  that  the  future  versions  of  CMS  will  support  the  product/process  consU'aint  mechanism  proposed 
in  MO.  Raytheon  plans  on  installing  the  June  release  of  the  CMS.  Raytheon  will  continue  to  develop  the 
process  selection  functionality  and  will  evaluate  the  CMS  when  it  is  available.  If  the  CMS  is  not  used,  the 
implemented  MO  process  selection  functionality  will  include  mechanisms  such  that  it  can  be  integrated  into  the 
protluct  team  environment  as  a  module. 

The  types  of  constraints  that  the  next  CMS  version  will  be  able  to  handle  are  the  bidirectional  constraint 
represented  by  algebraic  equations  linked  to  Maihematica™,  and  the  blackbox  constraint  (unidirectional)  which 
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receive  input  and  produce  output  through  the  evaluation  of  an  external  analysis  program.  Many  of  the 
constraints  that  the  MO  system  would  require  come  in  the  form  of  conditional  and  logical  constraints.  In  order 
to  integrate  the  first  release  of  the  CMS,  we  would  have  to  utilize  the  blackbox  constraint  by  writing  our  own 
external  analysis  program  that  would  take  our  constraint  format  as  input  and  return  the  result  as  output. 

Raytheon  reviewed  the  PCB  and  CM  which  will  be  integrated  with  the  September  version  of  the  CMS 
software.  Based  on  the  results  of  the  hands  on  PCB/CM  training  class,  Raytheon  saw  a  potential  to  use  the 
tools  as  a  front-end  for  MO  data  model  entry  due  to  its  hierarchical  product  structure  display.  We  have 
reservations  about  the  maturity  of  the  system,  and  its  interfaces  with  other  systems  (i.e.  ROSE).  The 
recommended  plan  is  to  get  the  PCB/CM  software  installed  at  Raytheon  so  that  we  can  perform  an  internal 
evaluation  using  sample  MO  data.  During  our  evaluation,  we  would  be  able  to  determine  if  the  PCB/CM  would 
add  any  value  to  the  MO  environment  as  an  extension  to  the  CMS  or  as  a  front-end  for  MO  process  data  model 
entry. 

The  Requirements  Manager  (RM)  is  a  system  designed  to  manage  product  requirements,  specifications  and 
corporate  policies  to  support  concurrent  engineering.  Within  the  MO  program,  Raytheon  planned  to  use  the  RM 
for  manufacturability/producibility  guidelines.  Version  2.0  of  the  RM  was  installed  at  CERC,  but  is  not 
supported.  Raytheon  decided  to  wait  for  the  upcoming  release,  Version  3.0,  and  not  to  install  V2.0.  Raytheon 
attended  a  demonstration  of  the  RM  V3.0  at  the  DICE  Phase  IV  Kick-off  meeting.  According  to  announced 
plans,  the  RM  V3.0  will  be  available  for  beta  test  at  the  end  of  March  and  released  for  production  u.sc  at  the  end 
of  June.  Raytheon  has  maintained  a  dialogue  with  CIMFLEX  and  has  expressed  its  interest  in  being  a  beta  test 
site.  The  purpose  of  integrating  the  manufacturing  guideline  functionality  into  the  RM  is  to  give  the  “top  level” 
product  development  team  insight  into  manufacturing  requirements  apart  from  MO  analyses.  Raytheon  will 
continue  to  develop  the  MO  guideline  functionality  and  will  evaluate  the  RM  when  it  is  available.  If  the  RM  is 
not  used,  the  implemented  MO  guideline  functionality  will  include  mechanisms  such  that  it  can  be  integrated 
into  the  product  team  environment  as  a  module. 
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2.  Introduction 

The  Manufacturing  Optimization  (MO)  system  is  a  conceptual  refinement  to  the  original  DICE  virtual  tiger 
team  concept.  This  refinement  is  to  have  a  two  level  approach  with  a  product  virtual  team  having  a  global  view 
supported  by  information  supplied  by  lower  level  “specialized”  process  virtual  teams.  The  purpose  of  the 
Manufacturing  Optimization  (MO)  system  is  to  enable  each  manufacturing  specialist  to  participate  in  the 
product/process  development  activity  concurrently.  The  system  will  consist  of  a  set  of  tools  to  model  the 
manufacturing  processes  and  centralize  the  various  process  tradeoffs.  The  primary  mission  of  the  MO  system  is 
in  researching  and  developing  a  “generalized”  design  for  manufacturing  and  assembly  (DFMA)  environment 
capable  of  modelling  diverse  manufacturing  processes.  The  system  will  consist  of  five  software  modules:  process 
analysis,  yield/rework  modeler,  cost  estimator,  guidelines,  and  manufacturing  advisor.  Refer  to  reference  2  for 
more  details  on  the  MO  system.  The  secondary  mission,  and  subject  of  this  report,  is  the  “user  hardening”  of 
existing  concurrent  engineering  technology  by  applying  existing  DICE  Tools  to  DFMA. 

During  the  proposal  stage  of  MO,  Raytheon  did  a  preliminary  evaluation  of  the  concurrent  engineering 
tools  previously  developed  under  the  DICE  program.  The  evaluation  consisted  of  visits  to  both  CERC  and 
Rensselaer  Polytechnic  Institute  (RPI)  to  attend  demonstrations  and  presentations  of  DICE  tools.  Available 
technical  papers  for  each  of  the  DICE  tools  were  studied  by  the  proposal  team.  Each  of  the  tools  demonstrated  at 
the  CERC  appeared  to  be  somewhere  between  a  prototype  to  a  released  product.  Each  DICE  tool  had  been 
developed  and/or  demonstrated  either  stand-alone  or  partially  combined  on  a  single  technology  (e.g.  turbine 
blade).  Based  on  this  preliminary  evaluation,  the  ROSE  Database  Management  System  (DBMS),  ConsU'aint 
Management  System  (CMS),  and  Requirements  Manager  (RM)  were  identified  as  candidates  for  incorporation 
into  the  MO  system.  Raytheon  also  planned  on  using  the  EDEX  Express  editor  to  code  and  edit  Express 
schemas.  No  evaluation  of  the  EDEX  editor  was  planned  or  conducted  as  part  of  this  report. 

The  CMS  is  scheduled  to  be  integrated  with  the  Project  Coordination  Board  (PCB)  and  Communications 
Manager  (CM)  by  the  end  of  September  so  Raytheon  expanded  the  scope  of  the  evaluation  to  include  the  PCB 
and  CM  due  to  this  close  coupling  among  the  PCB,  CM  and  CMS. 

Raytheon  proposed  to  use  ROSE  to  store  and  manage  the  manufacturing  process  models,  CMS  to  constrain 
the  product  design  to  process  capabilities,  and  RM  to  manage  manufacturing  guidelines.  The  proposed  MO 
architecture  is  shown  in  Figure  2-1. 
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Figure  2-1.  Proposed  DICE  MO  Architecture 

The  purpose  of  the  evaluation  described  herein  was  to  determine  the  maturity  of  each  of  the  DICE  tools  and 
confirm  their  applicability  to  MO.  Where  the  tools  are  not  as  mature  as  expected,  Raytheon  has  propiosed 
alternative  approaches.  The  basic  evaluation  plan  was  to  install  the  latest  available  version  of  each  of  the  tools 
in  our  own  environment  and  test  the  tools  by  executing  a  sample  test  set  of  data  that  was  representative  of  the 
basic  MO  functionality.  The  remainder  of  this  report  is  devoted  to  the  methods,  assumptions,  and  procedures,  as 
well  as,  the  results,  conclusions,  and  recommendations  of  the  evaluation  of  each  of  the  tools  identified. 
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3.  ROSE  -  Rensselaer  Object  System  For  Engineering 

3.1  Methods,  Assumptions,  and  Procedures 

3.1.1  Overview 

ROSE  is  an  object-oriented  database  management  system  that  has  been  developed  for  engineering 
applications  and  enhanced  to  support  the  DICE  program.  The  ROSE  Database  Management  System  is  a  database 
that  supports  concurrency  using  a  data  model  that  allows  the  differences  between  two  design  versions  to  be 
computed  as  a  delta  file.  ROSE  will  be  used  to  store  and  manage  the  data  files  for  the  manufacturing  processes 
and  operations,  as  well  as,  the  various  analysis  results.  Its  proposed  use  in  the  MO  system  is  to  store  the  process 
routing  sequence  which  will  enable  us  to  do  comparisons  of  process  trade-offs  via  the  delta  files.  The  process 
database  consists  of  the  process  selection  knowledge  base,  process/operation  data,  yield/rework  data,  guidelines, 
and  recommendations. 

The  EDEX  Editor  is  an  editor  that  has  been  developed  to  support  EXPRESS  schema  creation  and 
manipulation  for  ROSE.  EDEX  will  be  used  to  code  and  edit  the  manufacturing  process  model  schema(s). 

3.1.2  Proposed  Use  In  MO 

The  MO  system  will  consist  of  five  software  modules:  piocess  analysis,  yield/rework  modeler,  cost 
estimator,  guidelines,  and  manufacturing  advisor.  The  process  analysis  module  performs  the  initial  analysis  on 
the  design  to  determine  the  manufacturing  process  required  to  produce  the  part.  This  module  will  take  a 
knowledge  based  approach  that  will  compare  design  features  and  attributes  against  process  capabilities  to 
determine  a  part’s  process  sequence.  The  actual  process  will  be  modelled  as  a  hybrid  decision  tree  with  rules 
attached  to  each  node  of  the  tree.  The  decision  tree  informs  the  user  of  the  basic  flow  of  the  overall  process 
while  letting  the  user  plan  at  various  levels  of  abstraction.  These  levels  include  the  process,  operation,  and 
operational  step.  The  process  is  an  organized  group  of  manufacturing  operations  sharing  characteristics,  the 
operation  is  a  common  unit  of  work  that  is  performed  on  the  part,  and  the  operational  step  is  an  elemental  unit 
of  work  within  an  operation.  Before  an  analysis  can  be  run  on  a  design,  the  process  database  must  be  populated. 
The  process  database  consists  of  the  process  selection  knowledge  base,  process/operation  data,  yield/rework  data, 
cost  data,  guidelines,  and  recommendations.  We  propose  to  have  the  ROSE  DBMS  manage  all  the  process  model 
data. 


Once  the  process  database  is  populated,  evaluation  of  the  design  is  possible.  The  process  analysis  module 
c.xccutcs  the  process  knowledge  base  to  select  a  process  and  establish  the  list  of  operations  that  will  produce  the 
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part.  After  the  operation  sequence  is  determined,  each  applicable  operation  is  evaluated  to  calculate  yield  and 
rework  values.  These  values  are  established  by  the  relationship  between  the  design  and  the  operation.  The  cost  is 
calculated  based  on  the  labor  standards  associated  with  each  operation  which  are  factored  by  the  yield  and 
rework  values.  This  method  accounts  for  the  cost  of  scrap  and  rework.  We  plan  to  store  the  analysis  results  in 
the  ROSE  DBMS. 

Once  each  participating  team  member  has  run  an  analysis  within  the  MO  system,  the  data  is  consolidated 
within  ROSE  through  the  manufacturing  advisor  module.  The  advisor  organizes  the  data  by  summarizing 
processes,  guideline  violations,  and  recommendations.  From  this  summary,  the  process  team  members  can 
identify  major  costs  drivers  and  prioritize  change  recommendations.  These  recommendations  could  then  be  sent 
to  the  product  team.  The  process  team  could  also  elect  to  re-run  each  analysis  using  the  recommended  changes  to 
compare  the  costs  of  the  proposed  design  with  the  original  design. 

3.1.3  Evaluation  Plan 

Raytheon  developed  a  set  of  test  cases  to  demonstrate  the  applicability  of  the  ROSE  DBMS  to  adequately 
model  the  manufacturing  process  models  and  analysis  data.  We  modelled  the  three  levels  of  the  decision  tree 
abstraction  in  the  EXPRESS  information  modelling  language  so  that  we  could  create  (populate)  a  sample 
manufacturing  process  model  database.  We  used  the  actual  process  model  we  stored  in  ROSE  to  select  two 
different  process  plan  sequences  and  store  those  results  in  another  ROSE  database.  Finally,  we  read  in  the  list  of 
process  plan  results  so  that  we  could  evaluate  the  process  of  capturing  results  from  a  ROSE  database  for  the 
manufacturing  advisor  module  to  perform  comparisons  and  summations.  Detailed  below  are  the  actual  steps  that 
we  performed  to  evaluated  the  ROSE  DBMS. 

Step  1:  Installed  a  copy  of  the  Step  Tool  Kit  (ROSE)  Release  1  that  was  sent  to  us  from  Step  Tools  Inc. 

Step  2:  Performed  the  eight  tutorial  lessons  provided  in  the  ROSE  Tutorial  Manual  (Reference  6)  to  become 
familiar  with  ROSE  functionality  and  features. 

Step  3:  Modelled  a  small  sample  of  the  process  model  data  (jwocess  decision,  operation,  operational  step,  and  a 
process  plan/sequence)  using  the  EXPRESS  information  modelling  language. 

Step  4:  Generated  the  C-h-  classes  for  each  entity  in  the  EXPRESS  schema  using  the  “express2c-H-”  tool. 

Step  5:  Compiled  the  generated  C++  classes. 

Step  6:  Wrote,  compiled,  and  ran  a  C++  program  (ROSE  Appheation)  which  created  instances  (STEP  objects) 
of  the  generated  C++  classes  from  an  input  ASCII  data  file. 

Step  7:  Created  the  input  ASCII  file  for  the  above  C++  program. 

Step  8:  Wrote,  compiled,  and  ran  a  C++  program  (ROSE  Application)  that  read  in  the  instantiated  process 
model  ROSE  database  and  then  selected,  created,  and  stored  two  process  plan/scquence  objects. 
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Step  9:  Wrote,  compiled,  and  ran  a  C++  program  (ROSE  Application)  that  read  the  process  plan  database 
(output  of  the  above  program)  into  memory. 

Step  10:  Coordinated  with  the  GE  developers  to  acquire  a  copy  of  the  latest  version  of  the  EDEX  editor  for  us 
to  try  during  our  EXPRESS  information  mc^elling  development  efforts  for  the  MO  system. 

3.2  Results  and  Discussion 

We  installed  the  Step  Tool  Kit  that  we  received  from  Step  Tools  Inc.  and  performed  the  eight  tutorial 
lessons  provided  in  the  ROSE  Tutorial  Manual  (Reference  6).  This  provided  us  with  an  understanding  of  the 
basic  ROSE  functionality.  After  the  initial  learning  curve,  we  developed  a  sample  schema  to  test  the 
applicability  of  the  ROSE  DBMS  to  adequately  model  the  manufacturing  process  model  and  analysis  data  using 
the  EXPRESS  information  modelling  language  (refer  to  Appendix  I  section  10).  "^his  schema  modelled  a  small 
sample  of  the  basic  process  model  data  types.  Included  are  entities  for  a  process  decision,  operation,  operational 
step,  and  a  process  plan/sequence.  We  modelled  the  operation  and  operational  step  entities  as  subtypes  of  the 
process  decision.  The  process  plan/sequence  was  then  modelled  as  a  list  of  process  decisions.  Since  we  utilized 
inheritance  when  modelling  the  operation  and  operational  step,  a  process  plan/sequencc  would  be  able  to  contain 
a  process  decision,  operation,  and/or  operational  step.  After  developing  the  EXPRESS  schema,  we  used  the 
“express2c++”  tool  provided  in  the  toolkit  to  generate  the  C++  classes  for  each  of  the  entities  in  the  schema. 
Refer  to  Appendix  I  section  20  for  complete  details  on  all  the  “express2c++”  generated  class  code.  Following  is 
a  diagram  which  depicts  the  process  model  express  schema  versus  the  corresponding  “express2c++"  generated 
classes. 
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SCHEMA  prac«ss_mod«l; 

ENTrTY  DMialon; 
nama;  STRING; 
parent:  STRING; 
rules:  LIST  JO:?]  OF  STRING; 
END_ENTnV; 

ENTITY  Operation 
SUBTYPE  OF  (Oeciaion); 
op  desc:  STRING; 
bUr  cods:  INTEGER; 
ENO_ENTITY; 

ENTITY  Step 
SUBTYPE^F  (Decision); 
stap_no:  INTEGER; 
step  desc:  STRING; 
cutt(ng_tool:  STRING; 
no_passes:  INTEGER; 
step  time:  REAL; 

ENDIENTITY; 

ENTITY  Process; 
sequence:  LIST  [0:?]  OF  Decision; 
END_ENTITY; 

END_SCHEMA; 


axpress2C'M 


Dscteton  Class 

Instance  Variables 


Meltiods 


Oporatlon  Classr 


ranaiM 

mpmm  I 
MmlM  J 


Suh*Yp»  of  Pocision 

Instance  Variables 


Step  Class: 


Subtype  of  Decision 


Methods 


4ac0  r«)n^  desc 

>np_cod«0  laun  ndlcnde 

op.d«Bc(Silt  aap_4Mc)  m. 

M.eod<M  sM.CBdc)  sal  M.cnds 


Instance  Variables 


■V.dacO 

0111*11.  BolO 


■^.■o(wi  AJUB,*o) 

■^.dBc<STt  Mup_d*ac)  sa  a^.dSK 
QutB^BoVSrt  saMiBf_ieal)  M  aiuit_ioal 
■)  s«*e..paMB 

nc)  Md  . 


nns/ftoa  ■ 


Process  Class 


Figure  3-1.  Process_Model  EXPRESS  Schema  versus  Generated  C-i-i-  Classes 


The  next  step  involved  the  compilation  of  the  generated  C++  class  code.  When  compiling  the  classes,  the 
compiled  process  model  schema  was  generated  which  represents  the  data  structure  definitions.  Appendix  I 
section  30  contains  a  print  out  of  the  compiled  process  model  schema. 


To  test  how  ROSE  could  handle  storage  of  a  manufacturing  process  model  database,  we  developed  a  ROSE 
Application  (Appendix  I  section  40)  that  would  use  the  generated  C++  classes  to  create  instances  of  the  STEP 
objects  by  reading  in  sample  data  from  an  ASCII  input  file.  The  ASCII  input  file  (refer  to  Appendix  I  section 
50)  contains  a  series  of  process  decisions,  operations,  and  operational  steps.  The  program  created  the  STEP 
objects  that  were  represented  in  the  input  file  and  finally  stored  all  the  objects  in  the  process  model  database  as 
a  List  of  Decisions.  The  output  database  from  the  execution  of  the  ROSE  Application  can  be  found  in  Appendix 
I  section  60. 


A  major  part  of  what  MO  expects  ROSE  to  handle  is  the  storage  of  a  particular  process  sequence  which 
will  be  generated  by  the  process  analysis  module  inside  the  MO  system.  To  test  the  ability  of  ROSE  to  handle 
this  type  of  data,  we  developed  a  ROSE  Application  (Appendix  I  section  70)  that  read  in  the  process  model 
database  that  we  previously  generated,  and  then  selected  two  sequences  of  decision  objects  based  on  their  name. 

8 


UNCLASSIFIED 
CDRL  No.  (XX)2AC-2 


We  then  created  and  stored  these  decision  objects  as  two  process  objects.  Refer  to  Appendix  I  section  80  for  a 
complete  pnnt  out  of  the  output  (ntxess  plan/sequence  database. 

Finally,  to  test  the  ease  in  which  we  could  read  a  complete  list  of  process  plan/sequence  objects  back  into 
memory  for  the  manufacturing  advisor  module  to  perform  comparisons  and  summations,  we  developed  a  ROSE 
Application  (Appendix  I  section  90)  that  simply  read  the  previously  generated  process  plan/sequence  database 
into  memory. 


We  contacted  General  Electric  (GE)  about  obtaining  a  copy  of  the  Editor  for  EXPRESS  (EDEX)  that  was 
developed  as  an  extension  to  the  emacs  editor  which  would  help  navigate  through  complex  EXPRESS  schemas. 
Raytheon  has  received  documentation.  GE  will  contact  us  in  the  near  future  to  send  us  the  EDEX  editor.  The 
plan  is  to  install  the  EDEX  editor  on  our  system  so  that  we  can  use  it  during  our  MO  development  efforts. 


Learning  the  basics  of  the  ROSE  DBMS  with  the  aid  of  the  reference  and  tutorial  manuals  provided  with 
the  software  (References  4  and  6)  was  straightforward.  To  better  understand  the  more  advanced  features  of 
ROSE,  we  plan  on  attending  one  of  the  training  sessions  conducted  by  Step  Tools.  Based  on  the  results  of  our 
sample  test  case,  we  believe  that  the  ROSE  DBMS  is  able  to  handle  the  various  types  of  manufacturing  process 
model  and  analysis  data  required  in  the  MO  environment.  Refer  to  Table  3-1  for  a  summary  of  the  evaluation 
results  of  the  system. 


Table  3-1.  Summary  of  the  ROSE  Evaluation  Results 


System  Under 
Evaluation 

MO  Applicability 

Maturity/ Availability 

Conclusion/ 

Recommendation 

ROSE 

Model,  Store,  and 
Manage  Process  Model 
and  Analysis  Data. 

Stable.  No  difficulty 
with  installation  or 
evaluation  procedures. 

Plan  on  continuing 
integration  efforts. 

EDEX  Editor 

Code  and  edit  MO 
Express  Schemas. 

No  evaluation  planned 
or  conducted. 

Plan  to  install. 
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4.  CMS  -  Constraint  Management  System 

4.1  Methods,  Assumptions,  and  Procedures 

4.1.1  Overview 

The  Constraint  Management  System  allows  the  user  to  build  constraints  into  the  concurrent  engineering 
process.  The  system  tracks  constraints  and  can  notify,  or  launch  an  evaluation  when  constraints  are  not  satisfied. 
The  CMS  will  be  used  to  manage  the  constraint  placed  on  the  design  by  the  capabilities  of  the  process  required 
by  the  MO  system. 

The  Project  Coordination  Board  (PCB)  is  a  system  being  developed  to  provide  support  for  the 
coordination  of  the  product  development  activities  in  a  cooperative  environment.  The  PCB  provides  common 
visibility  and  change  notification  through  the  common  workspace,  planning  and  scheduling  of  activities  through 
the  task  structure,  monitoring  progress  of  product  development  through  the  product  structure  (i.e.  constraints), 
and  computer  support  for  team  structure  through  messages.  This  tool  is  currently  integrated  with  the  CM,  and 
the  CMS  is  scheduled  to  be  integrated  with  the  PCB  by  the  second  pilot  site  release. 

The  Communications  Manager  (CM)  is  a  collection  of  modules  that  facilitates  distributed  computing  in  a 
heterogeneous  network.  It  promotes  the  notion  of  a  virtual  network  of  resources  which  the  project  team  members 
can  exploit  without  any  prior  knowledge  of  the  underlying  physical  network.  The  CM  would  be  useful  for  those 
that  would  like  to  build  transparent  tools,  virtual  project  networks,  have  access  to  remote  tools,  perform  network 
tasks,  perform  message  passing,  and/or  perform  inter-process  file  transfers. 

4.1.2  Proposed  Use  In  MO 

The  rules  that  determine  the  selection  (or  evaluation)  of  operations  within  the  MO  system  can  be  modelled 
as  a  set  of  constraints.  If  the  constraints  are  satisfied  then  the  operation  can  produce  the  pan  or  feature  (based  on 
scope  of  rule  set).  If  the  rules  or  constraints  of  the  operation  are  not  satisfied  then  the  operation  is  not  valid  for 
use.  By  interfacing  with  the  constraint  manager,  these  process/operation  rules  can  monitor  the  design  and  be 
informed  when  the  design  has  exceeded  process  capabilities.  This  can  function  by  informing  the  team  that  the 
current  design  is  limiting  process  alternatives  or  that  the  initial  process  evaluated  for  the  design  is  no  longer 
valid  and  a  re-evaluation  must  be  performed.  In  this  scenario  tbe  re-evaluation  will  result  in  a  process  change. 

For  this  function  or  set  of  functions,  Raytheon  planned  two  approaches.  The  first  one  would  enable  the 
manufacturing  specialist  to  run  the  system  and  determine  the  consuaint  or  requirement  violations  and 
interrelationships  from  the  MO  program.  The  second  approach  would  integrate  that  piece  of  the  analysis  in 
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another  DICE  tool  so  that  the  product  team  could  be  informed  of  the  analysis  immediately.  The  CMS,  PCB,  and 
the  CM  are  the  DICE  tools  considered  for  use  in  the  second  approach. 

4.1.3  Evaluation  Plan 

The  Constraint  Management  System  went  though  initial  development,  and  was  loaded  onto  the  CERC 
testbed  and  tested.  From  the  results  of  the  testing,  the  CMS  was  found  to  be  unsuitable  for  pilot  (beta)  site 
installation.  A  future  release  of  the  CMS  will  be  integrated  with  the  PCB  and  CM. 

Raytheon  received  papers  on  the  CMS  and  read  these  as  a  comparison  to  requirements  prior  to  our  CERC 
visit.  To  conduct  the  evaluation  of  the  CMS  without  benefit  of  site  installed  software,  Raytheon  planned  a  visit 
to  CERC  to  attend  a  demonstration  of  the  CMS  and  meet  with  the  developers.  The  trip  coincided  with  the 
CERC  PCB/CM  training  session  so  Raytheon  also  attended  the  two  day  class  to  gain  insight  into  the 
functionality  of  the  PCB  and  CM  since  the  CMS  is  scheduled  to  be  integrated  with  the  PCB/CM. 

4.2  Results  and  Discussion 

Prior  to  visiting  CERC,  we  read  two  papers  (Reference  3  and  5)  on  the  CMS  so  that  we  could  compare  the 
requirements  outlined  in  the  paper  with  the  scheduled  first  release  requirements.  On  February  26th  and  27th, 
Raytheon  received  a  demonstration  of  the  current  version  of  the  Constraint  Management  System  (CMS),  and 
attended  a  two  day  training  class  on  the  Project  Coordination  Board  (PCB)  and  Communications  Manager 
(CM)  at  CERC.  The  June  release  of  the  CMS  will  be  a  stand-alone  version  running  on  UNIX  platforms.  The 
September  release  of  the  system  will  be  integrated  with  the  PCB/CM.  The  PCB  and  CM  software  will  be 
provided  to  us  from  CERC  as  soon  as  possible  so  that  we  can  perform  our  own  internal  evaluation.  Draft  copies 
of  the  PCB  User  Manual  and  three  CM  Programmer’s  Manuals  were  provided  at  the  Gaining  class. 

The  purpose  of  the  CMS  is  to  provide  mechanisms  to  effectively  represent,  manage  and  satisfy  the 
consuaints  imposed  on  a  product  and  its  development.  This  is  done  through  a  collection  of  modules.  One 
module  allows  for  the  creation  and  modification  of  con.straints.  Another  module  is  used  to  manage  the 
constraints,  maintain  consistency  of  the  consuaint  network,  evaluate  consuaints,  and  propagate  variable  values 
when  necessary.  Additional  modules  include  a  constraint  propagation  planner  and  a  module  to  perform  interval 
mathematics  which  is  linked  to  Mathematica™.  The  possible  forms  that  conshaints  could  take  include  algebraic 
{equality/ inequality  and  linear! nonlinear),  numeric  {table  look-up),  conditional  {if-then),  logical  {"X  and  T”), 
bidirectional  (i.e.  x''3l(e'^23)  =  3.8y),  and  unidirectional  {blackbox).  The  types  of  constraints  that  the  the  first 
pilot  site  release  will  be  able  to  handle  are  the  bidirectional  constraint  represented  by  algebraic  equations  (linked 
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to  Mathematica™)  and  the  blackbox  constraint  (unidirectional)  which  receive  input  and  produce  output  through 
the  evaluation  of  an  external  analysis  program.  The  first  release  of  the  CMS  will  not  have  a  user-friendly 
windowing  interface,  it  will  be  command  line  driven.  Many  of  our  constraints  for  the  MO  system  come  in  the 
form  of  conditional  and  logical  constraints.  For  example,  a  constraint  for  the  sheet  metal  panel/chassis 
environment  could  be  “IF  single_diameter_hole  AND  material_thickness  =  0.125  AND  maximum_bend_radius 
=  0.125  AND  minimum_distance_to_edge_of_bend  <  0.348  THEN  punch  ELSE  drill_at_assembly”.  If  we  plan 
to  integrate  the  first  release  of  the  CMS,  we  would  have  to  utilize  the  blackbox  constraint  by  writing  our  own 
external  analysis  program  that  would  take  our  constraint  format  as  input  and  return  the  result  as  output. 

As  explained  earlier,  the  PCB  is  a  system  being  developed  to  provide  support  for  the  coordination  of  the 
product  development  activities  in  a  cooperative  environment  The  PCB  provides  common  visibility  and  change 
notification  through  the  common  workspace  (cw),  planning  and  .scheduling  of  activities  through  the  task 
structure,  monitoring  progress  of  product  development  through  the  product  su^ucture,  and  computer  support  for 
team  structure  through  messages.  The  PCB  is  composed  of  two  modules:  the  cw  (Common  Workspace)  module 
and  the  da  (Design  Agent)  module.  The  cw  module  provides  the  functionality  for  project  coordination,  and  the 
da  module  is  an  interface  provided  to  product  developers  so  they  can  interact  with  the  cw  module.  The  CM 
Communication  Services  (CS),  the  CM  Directory  Services  (DS),  and  the  CM  Application  Management 
Services  (AMS)  must  be  up  and  running  for  the  PCB  to  work.  For  a  given  cw  running  there  can  be  zero  or 
more  da’s  running  at  a  given  point  in  time.  It  is  also  possible  to  have  more  than  one  cw  running  at  a  time. 
Currendy,  the  PCB  expects  that  you  will  plan  your  activities  (project  plan)  in  MacProject  II  and  import  that 
task  sumeture  into  the  PCB.  The  user  can  view  any  task  or  work  order  that  appears  in  their  network,  add  a  task 
to  the  existing  network,  can  acknowledge  receiving  a  task,  and  indicate  completion  of  their  task.  The  PCB  will 
automatically  dispatch  a  task  as  previous  tasks  are  completed,  as  well  as,  the  Project  Lead  (uscr(s)  with  special 
privileges)  can  dispatch  a  task.  The  product  structure  can  be  loaded  through  a  file  or  by  using  the  Knowledge 
Server  (i.e.  importing  from  a  ROSE  database).  Once  the  product  structure  is  loaded,  it  is  displayed  using  a 
hierarchical  browser.  The  PCB  allows  the  user  to  view  (objects,  constraints,  and  assertions),  edit  (object, 
attribute,  and  value),  assert  (values,  constraints,  and  profiles),  and  .save,  load,  or  clear  the  knowledge  base  (kb). 
When  the  users  are  logged  out  of  the  PCB,  messages  concerning  the  release  of  new  product  models,  constraint 
violations  on  attributes  on  which  users  have  set  a  perspective,  and  any  tasks  that  have  been  assigned  are 
maintained  for  them  and  can  be  viewed  at  their  convenience. 

Since  the  PCB  di.splays  the  product  structure  in  a  hierarchical  fashion,  Raytheon  considered  using  the  PCB 
as  the  front-end  for  the  MO  data  model  entry.  The  limitation  of  this  PCB  function  is  that  it  can  import 
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information  into  the  PCB  using  the  Knowledge  Server,  but  the  only  output  format  is  its  kb  file.  We  were 
hoping  that  it  would  not  only  be  able  to  import  the  product  structure  from  the  ROSE  database,  but  also  to 
export  the  product  structure  to  ROSE  since  our  current  plan  is  to  store  all  the  MO  data  in  ROSE.  They  said  that 
there  are  plans  to  provide  this  type  of  link  because  it  has  been  requested  by  other  pilot  sites,  but  they  could  not 
provide  us  with  a  delivery  date.  We  will  request  a  copy  of  the  Knowledge  Server  from  CERC  so  that  we  can 
test  the  ROSE  to  PCB  link. 


The  CM  is  a  collection  of  modules  that  facilitates  distributed  computing  in  a  heterogeneous  network.  It 
promotes  the  notion  of  a  virtual  network  of  resources  which  the  project  team  members  can  exploit  without  any 
prior  knowledge  of  the  underlying  physical  network.  The  CM  is  useful  for  those  that  who  are  building 
transparent  tools,  virtual  project  networks,  have  access  to  remote  tools,  perform  network  tasks,  perform  message 
passing,  and/or  perform  inter-process  file  transfers.  The  general  functions  of  the  CM  include  five  modules;  the 
session,  network  resource  service  (DS),  application  management  service  (AMS),  task  management  service 
(TMS),  and  the  communication  service  (CS).  The  session  provides  transparent  and  robust  communication  for 
programmers  between  a  server  and  a  client  which  aids  in  the  building  of  transparent  tools.  The  network  resource 
service  (DS)  provides  a  database  of  network  information  for  the  end  users,  programmers,  and  CM  administrator 
through  the  use  of  the  CM  directory  services  (Virtual  Project  Network).  The  application  management  service 
(AMS)  allows  remote  execution  of  applications  for  programmers  and  CM  administrators.  The  task  management 
service  (TMS)  provides  scheduling  and  distributing  of  jobs  on  a  network  for  end  users  by  creating  a  task  file, 
comp,  ing  a  task  file,  and  executing  a  task  file.  The  communication  service  (CS)  is  a  communication  package  for 
inter-process  file  transfers  for  programmers. 


Table  4-1.  Summary  of  the  CMS  Evaluation  Results 


System  Under 
Evaluation 

MO  Applicability 

Maturity/Availability 

Conclusion/ 

Recommendation 

CMS 

Model  Process  Model 
Rules  as  a  set  of 
Constraints. 

Immature.  Not  available 
for  pilot  site  installation 
until  June. 

Install  and  evaluate  in 
June. 

PCB 

Scheduled  for 
integration  with  the 

CMS  by  the  end  of 
September. 

Immature.  Attended 
training  session,  and 
scheduled  for  software 
installation  as  soon  as 
possible. 

Install  and  evaluate  as 
soon  as  possible. 

CM 

Currently  integrated 
with  the  PCB,  and  will 
be  required  when 
PCB/CM  is  integrated 
with  the  CMS  at  the 
end  of  September. 

Immature.  Attended 
training  session,  and 
scheduled  for  software 
installation  as  soon  as 
possible. 

Install  and  evaluate  as 
soon  as  possible. 
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5.  RM  -  Requirements  Manager 

5.1  Methods,  Assumptions,  and  Procedures 

5.1.1  Overview 

The  Requiremenis  Manager  is  a  system  designed  to  manage  product  requirements,  specifications  and 
corporate  policies  to  support  concurrent  engineering.  The  system  allows  the  users  to  define  requirements  for  a 
project  or  incorporate  standard  requirements  through  pointers  (file  name).  The  system  also  tracks  parties 
interested  in  specific  requirements  and  provides  notification  capabilities  based  on  the  status  of  a  requirement. 
Status  updates  could  include  modifications  of  a  requirement,  product  design  driven  violations  of  a  requirement, 
or  satisfaction  of  a  requirement. 

5.1.2  Proposed  Use  In  MO 

The  purpose  of  integrating  the  MO  manufacturing  guideline  functionality  into  the  RM  is  to  give  the  “top 
level”  product  development  team  insight  into  manufacturing  requirements  apart  from  MO  analyses. 

It  is  common  practice  for  a  manufacturer  to  document  manufacturability,  or  producibility,  guidelines  that 
delineate  standard  manufacturing  practices  and  acceptable  design  parameters.  The  purpose  of  these  guidelines  is 
to  communicate  the  capabilities  of  the  manufacturing  process  to  the  product  design  community  to  ensure  that 
new  product  designs  are  specified  within  manufacturing  capabilities.  The  guidelines  delineate  quantitative  and 
qualitative  producibility  issues. 

One  of  the  functions  of  MO  is  to  provide  evaluation  of  manufacturing  guidelines.  For  each  guideline  enuw 
there  is  a  related  recommendation.  The  guidelines  can  be  evaluated  separately,  or  triggered  based  on  the  process 
analysis  module  within  the  MO  system.  Unlike  the  process  selection  constraints,  manufacturability  guideline 
violations  may  not  cause  alternative  selection.  The  result  could  be  an  operation  cost  increase,  for  instance,  the 
need  for  non-standard  tooling,  a  yield  loss,  or  a  less  tangible  impact  These  guidelines  will  also  be  entered  into 
the  Requirements  Manager  so  that  they  are  available  to  the  product  design  team  along  with  the  other 
requirements  placed  on  the  design. 

5.1.3  Evaluation  Plan 

The  latest  version  of  the  RM  is  Version  2.0.  Although  this  version  was  installed  at  CERC,  it  is  not 
supported.  While  at  the  DICE  Phase  IV  Kick-off  meeting,  we  planned  to  attend  a  demonsuation  of  the  RM  V3.0. 
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Raytheon  has  maintained  a  dialogue  with  CIMFLEX  Teknowledge  and  has  expressed  its  interest  in  being  a  beta 
test  site. 

5.2  Results  and  Discussion 


The  Requirements  Manager  (RM)  is  a  system  designed  to  manage  product  requirements,  specifications  and 
corporate  policies  to  support  concurrent  engineering.  Within  the  MO  program,  Raytheon  planned  to  use  the  RM 
for  manutacturability/'producibility  guidelines.  Version  2.0  of  the  RM  was  installed  at  CERC,  but  is  not 
supported.  Raytheon  decided  to  wait  for  the  upcoming  release.  Version  3.0,  and  not  to  install  V2.0.  Raytheon 
attended  a  demonstration  of  the  RM  V3.0  at  the  DICE  Phase  IV  Kick-off  meeting.  According  to  announced 
plans,  the  RM  will  be  available  for  beta  test  at  the  end  of  March  and  released  for  production  use  at  the  end  of 
June.  Raytheon  has  maintained  a  dialogue  with  CIMFLEX  and  has  expressed  its  interest  in  being  a  beta  test 
site.  The  purpose  of  integrating  the  manufacturing  guideline  functionality  into  the  RM  is  to  give  the  “top  level” 
product  development  team  insight  into  manufacturing  requirements  apart  from  MO  analyses.  Raytheon  will 
continue  to  develop  the  MO  guideline  functionality  and  will  evaluate  the  RM  when  it  is  available.  If  the  RM  is 
not  used,  the  implemented  MO  guideline  functionality  will  include  mechanisms  such  that  it  can  be  integrated 
into  the  product  team  environment  as  a  module. 


Table  5-1.  Summary  of  the  RM  Evaluation  Results 


System  Under 
Evalustlon 

MO  Applicability 

Maturity/ Availability 

Conclusion/ 

Recommendation 

RM 

Immature.  RM  V3.0  not 
available  for  pilot 
installation. 

Install  and  evaluate  RM 
V3.0  when  available. 
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6.  Conclusions 

The  evaluation  plan  for  each  of  the  DICE  tools  considered  for  incorporation  into  the  MO  system 
environment,  ROSE  DBMS,  CMS,  PCB,  CM,  and  RM,  was  performed.  Table  6-1  contains  the  summary  of  the 
evaluation  results. 

After  installing  the  Step  Tool  Kit  (ROSE  DBMS)  and  performing  the  eight  tutorial  lessons  provided  in 
the  ROSE  Tutorial  Manual  (reference  6),  we  felt  that  we  had  obtained  an  understanding  of  the  basic  ROSE 
functionality.  We  continued  by  developing  a  set  of  test  cases  to  demonstrate  the  applicability  of  the  ROSE 
DBMS  to  adequately  model  manufacturing  process  models  and  analysis  data.  This  involved  writing  an 
EXPRESS  schema  to  represent  a  sample  of  the  process  model  data,  generating  the  C++  classes  with  the  use  of 
the  “express2c++”  tool,  and  writing,  compiling  and  executing  various  ROSE  Applications  (C++  programs). 
The  developers  learned  the  basics  of  the  ROSE  DBMS  with  the  use  of  the  reference  and  tutorial  manuals 
provided  with  the  software  (References  4  and  6).  To  learn  the  more  advanced  features  of  ROSE,  Raytheon  plans 
on  attending  one  of  the  training  sessions  conducted  by  STEP  Tools.  Raytheon  believes  that  ROSE  is  quite 
stable.  We  encountered  no  difficulties  during  the  installation  or  evaluation  procedures.  Based  on  the  results  of 
our  sample  test  case,  we  believe  that  ROSE  is  able  to  handle  the  various  types  of  manufacturing  process  model 
and  analysis  data  required  in  the  MO  environment  so  we  are  planning  on  continuing  the  integration  efforts  with 
the  ROSE  System. 

Since  there  was  no  pilot  site  version  of  the  CMS  software  available,  Raytheon  visited  CERC  to  received  a 
demonstration  of  the  current  version  of  the  Constraint  Management  System  (CMS).  The  purpose  of  the  CMS  is 
to  provide  mechanisms  to  effectively  represent,  manage  and  satisfy  the  consu-aints  imposed  on  a  product  and  its 
development.  The  possible  forms  that  a  Constraints  Manager  would  need  include  algebraic  {equality ! inequality 
and  linearinonlinear),  numeric  {table  look-up),  conditional  {if-then),  logical  {"X  and  Y”),  bidirectional  (i.e. 
x^3/(e''2.3)  =  3.8y),  and  unidirectional  {blackbox).  The  types  of  constraints  that  the  the  first  pilot  site  release 
will  be  able  to  handle  are  the  bidirectional  constraint  represented  by  algebraic  equations  (linked  to 
Mathematica™),  and  the  blackbox  constraint  (unidirectional)  which  receive  input  and  produce  output  through 
the  evaluation  of  an  external  analysis  program.  Many  of  our  constraints  for  the  MO  system  come  in  the  form  of 
conditional  and  logical  constraints.  For  example,  a  constraint  for  the  sheet  metal  panel/chassis  environment  could 
be  “IF  singIe_diamcter_hole  AND  matcrial_thickncss  =  0.125  AND  maximum_bend_radius  =  0.125  AND 
minimum_distance_to_edge_of_bend  <  0.348  THEN  punch  ELSE  drill_ai_asscmbly”.  If  after  the  evaluation  of 
the  first  release  of  the  CMS  we  continue  the  integration  efforts,  we  will  have  to  utilize  the  blackbox  constraint 
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by  writing  our  own  external  analysis  program  that  would  take  our  constraint  format  as  input  and  return  the 
result  as  output 

Since  the  CMS  is  scheduled  to  be  integrated  with  the  Project  Coordination  Board  (PCB)  and 
Communications  Manager  (CM),  Raytheon  attended  a  two  day  training  class  on  the  PCB  and  CM  at  CERC. 
The  PCB  is  a  system  being  developed  to  provide  support  for  the  coordination  of  the  product  development 
activities  in  a  cooperative  environment,  and  the  CM  is  a  collection  of  modules  that  facilitates  distributed 
computing  in  a  heterogeneous  network;  thereby,  promoting  the  notion  of  a  virtual  network  of  resources  which 
the  project  team  members  can  exploit  without  any  prior  knowledge  of  the  underlying  physical  network.  Since 
the  PCB  displays  the  product  structure  in  a  hierarchical  fashion,  Raytheon  considered  using  the  PCB  as  the 
front-end  for  the  MO  data  model  entry.  The  limitation  of  this  PCB  function  is  that  it  can  import  information 
into  the  PCB  using  the  Knowledge  Server,  but  the  only  output  format  is  its  knowledge  base  (kb)  file.  We  were 
hoping  that  it  would  not  only  be  able  to  import  the  product  structure  from  the  ROSE  database,  but  also  to 
export  the  product  structure  to  ROSE  since  our  current  plan  is  to  store  all  the  MO  data  in  ROSE.  The  CERC 
pilot  site  support  leader  said  that  there  is  plans  to  provide  this  type  of  link  becau.se  it  has  been  requested  by 
other  pilot  project  sites,  but  they  could  not  provide  us  with  a  delivery  date.  Since  the  Knowledge  Server  is  the 
software  that  is  required  to  translate  data  from  the  ROSE  database  into  the  PCB  database,  we  will  be  requesting 
a  copy  of  the  Knowledge  Server  from  CERC  so  that  we  can  test  the  ROSE  to  PCB  link.  When  Raytheon  gets  a 
copy  of  the  pilot  site  version  of  the  PCB/CM  software,  we  will  perform  our  own  internal  evaluation  which  will 
provide  us  with  a  basis  for  whether  or  not  the  systems  could  be  of  use  in  the  MO  environment.  We  plan  to 
continue  with  the  developed  approach  to  this  constraint  manager  function,  and  do  not  plan  to  incorporate  the 
CMS,  PCB,  or  CM  in  the  MO  design  until  after  careful  evaluation  of  each  of  the  released  systems. 

The  Requirements  Manager  (RM)  is  a  system  designed  to  manage  product  requirements,  specifications  and 
corporate  policies  to  support  concurrent  engineering.  Within  the  MO  program,  Raytheon  planned  to  use  the  RM 
for  manufacturability/producibility  guidelines.  Version  2.0  of  the  RM  was  installed  at  CERC,  but  is  not 
supported.  Raytheon  decided  to  wait  for  the  upcoming  release.  Version  3.0,  and  not  to  install  V2.0.  Raytheon 
will  continue  to  develop  the  MO  guideline  functionality  and  will  evaluate  the  RM  when  it  is  available.  If  the 
RM  is  not  used,  the  implemented  MO  guideline  functionality  will  include  mechanisms  such  that  it  can  be 
integrated  into  the  product  team  environment  as  a  module. 
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Table  6-1.  Summary  of  the  Evaluation  Results 


System  Under 
Evaluation 

MO  Applicability 

Maturity/ Availability 

Conclusion/ 

Recommendation 

Rose 

Model.  Store,  and 
Manage  Process  Model 
and  Analysis  Data. 

Stable.  No  difficulty 
with  installation  or 
evaluation  procedures. 

Plan  on  continuing 
integration  efforts. 

EDEX  Editor 

Code  and  edit  MO 
Express  Schemas. 

No  evaluation  planned 
or  conducted. 

Plan  to  install. 

Model  Process  Model 
Rules  as  a  set  of 
Constraints. 

Immature.  Not  available 
for  pilot  site  installation 
until  June. 

Install  and  evaluate  in 
June. 

PCB 

Scheduled  for 
integration  with  the 

CMS  by  the  end  of 
September. 

Immature.  Attended 
training  session,  and 
scheduled  for  software 
installation  as  soon  as 
possible. 

Install  and  evaluate  as 
soon  as  possible. 

CM 

Currently  integrated 
with  the  PCB.  and  will 
be  required  when 
PCB/CM  is  integrated 
with  the  CMS  at  the 
end  of  September. 

Immature.  Attended 
training  session,  and 
scheduled  for  software 
installation  as  soon  as 
possible. 

Install  and  evaluate  as 
soon  as  possible. 

RM 

Manage 

manufacturability/ 
producibility  guidelines. 

Immature.  RM  V3.0  not 
available  for  pilot 
installation. 

Install  and  evaluate  RM 
VS.O  when  available. 
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7.  Recommendations 


Raytheon  has  evaluated  the  ROSE  system,  the  Constraint  Management  System  (CMS),  and  the 
Requirements  Manager,  for  product  maturity  and  incorporation  into  the  MO  program.  The  evaluation  of  these 
tools  was  expanded  to  encompass  the  Project  Coordination  Board  (PCB)  and  the  Communications  Manager 
(CM)  because  they  are  closely  coupled  to  the  CMS.  Raytheon  recommends  using  the  ROSE  system  for  MO 
implementation.  At  present,  the  CMS  and  RM  axe  to  immature  to  commit  to  for  use  in  MO.  The  planned  release 
for  both  the  RM  and  CMS  are  during  the  early  stage  of  the  MO  design  cycle.  Therefore,  Raytheon  recommends 
that  both  tools  are  tracked  and  further  evaluation  conducted  when  these  tools  are  rclcjiscd.  A  final  determination 
will  be  made  at  that  time. 

Raytheon  proposed  to  use  ROSE  to  store  and  manage  the  process  models  and  analysis  data  for  the  MO 
system.  As  part  of  the  evaluation  process  of  ROSE,  we  developed  a  set  of  test  ca.ses  to  demonstrate  the 
applicability  of  the  ROSE  DBMS  to  adequately  model  the  manufacturing  process  models  and  analysis  data. 
Based  on  the  results  of  our  sample  test  case,  we  believe  that  the  ROSE  DBMS  is  able  to  handle  the  various 
types  of  manufacturing  process  model  and  analysis  data  required  in  the  MO  environment.  We  recommended  the 
continued  use  of  the  ROSE  DBMS  as  the  repository  for  all  the  process  data  files  for  the  manufacturing 
processes  and  operations,  as  well  as,  the  various  analysis  results  for  the  MO  system.  To  better  understand  the 
more  advanced  features  of  ROSE,  attending  one  of  the  three  day  sessions  that  Step  Tools  conducts  would  be  of 
great  assistance  in  our  future  MO  development  efforts. 

Raytheon  proposed  to  use  the  CMS  to  provide  a  mechanism  for  constraining  the  product  design  to  process 
capabilities.  Since  the  pilot  site  version  of  the  CMS  software  was  unavailable  for  testing,  Raytheon  planned  a 
trip  to  CERC  for  a  demonsttation  of  the  current  version  of  the  CMS  and  a  meeting  with  the  developers.  Based 
on  the  CERC  visit,  it  was  determined  that  the  future  versions  of  CMS  will  support  the  product/proccss 
consU'aint  mechanism  proposed  in  MO.  Raytheon  plans  on  installing  the  June  release  of  the  CMS.  Raytheon 
will  continue  to  develop  the  process  selection  functionality  and  will  evaluate  the  CMS  when  it  is  available.  If 
the  CMS  is  not  u.sed,  the  implemented  MO  process  selection  functionality  will  include  mechanisms  such  that  it 
can  be  integrated  into  the  product  team  environment  as  a  module. 

The  types  of  constraints  that  the  next  CMS  version  will  be  able  to  handle  arc  the  bidirectional  constraint 
represented  by  algebraic  equations  linked  to  Mathcmatica™,  and  the  blackbox  constraint  (unidirectional)  which 
receive  input  and  produce  output  through  the  evaluation  of  an  external  analysis  program.  Many  of  the 
constraints  that  the  MO  system  would  require  come  in  the  form  of  conditional  and  logical  constraints.  In  order 
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lo  integrate  the  first  release  of  the  CMS,  we  would  have  to  utilize  the  blackbox  constraint  by  writing  our  own 
external  analysis  program  that  would  take  our  constraint  format  as  input  and  return  the  result  as  output. 

Raytheon  reviewed  the  PCB  and  CM  which  will  be  integrated  with  the  September  version  of  the  CMS 
software.  Based  on  the  results  of  the  hands  on  PCB/CM  training  class,  Raytheon  saw  a  potential  to  use  the 
tools  as  a  front-end  for  MO  data  model  entry  due  to  its  hierarchical  product  structure  display.  We  have 
reservations  about  the  maturity  of  the  system,  and  its  interfaces  with  other  systems  (i.e.  ROSE).  The 
recommended  plan  is  to  get  the  PCB/CM  software  installed  at  Raytheon  so  that  we  can  perform  an  internal 
evaluation  using  sample  MO  data.  During  our  evaluation,  we  would  be  able  to  determine  if  the  PCB/CM  would 
add  any  value  to  the  MO  environment  as  an  extension  to  the  CMS  or  as  a  front-end  to  the  MO  process  data 
model  entry. 

The  Requirements  Manager  (RM)  is  a  system  designed  to  manage  product  requirements,  specifications  and 
corporate  policies  to  support  concurrent  engineering.  Within  the  MO  program,  Raytheon  planned  to  use  the  RM 
for  manufacturability/producibility  guidelines.  Version  2.0  of  the  RM  was  installed  at  CERC,  but  is  not 
supported.  Raytheon  decided  to  wait  for  the  upconi:;g  rclea'-e,  Version  3.0,  and  not  to  install  V2.0.  Raytheon 
will  continue  to  develop  the  MO  gui  'ciiiie  functionality  and  will  evaluate  the  RM  when  it  is  available.  If  the 
RM  is  not  used,  the  implemented  MO  guideline  functionality  will  include  mechanisms  such  that  it  can  be 
integrated  into  the  product  team  environment  as  a  module. 
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Notes 


Acronyms 

AMS 

Application  Management  Service 

CAEO 

Computer  Aided  Engineering  Operations 

CDRL 

Contract  Data  Requirement  List 

CM 

Communications  Manager 

CMS 

Constraint  Management  System 

cs 

Communication  Service 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DBMS 

Database  Management  System 

DFMA 

Design  for  Manufacturing  and  Assembly 

DICE 

DARPA  Initiative  In  Concurrent  Engineering 

DS 

Directory  Service 

EDEX 

Editor  for  EXPRESS 

GE 

General  Electric 

MO 

Manufacturing  Optimization 

PCB 

Project  Coordination  Board 

RM 

Requirements  Manager 

ROSE 

Rensselaer  Object  System  For  Engineering 

RPI 

Rensselaer  Polytechnic  Institute 

TMS 

Task  Management  Service 
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Appendix  I  -  ROSE  Evaluation  Data 
10.  Process  Model  EXPRESS  Schema 

SCHEMA  process_model; 

ENTITY  Decision; 
name:  STRING; 
parent:  STRING; 
rules:  LIST  [0:?]  OF  STRING; 

END_ENTITY; 

ENTITY  Operation 

SUBTYPE  OF  (Decision)  ; 
op_desc:  STRING; 
bid_code:  INTEGER; 

END_ENTITY; 

ENTITY  Step 

SUBTYPE  OF  (Decision)  ; 

Step_no:  INTEGER; 
step_desc:  STRING; 
cutting_tool :  STRING; 
no_passes:  INTEGER; 
step_time:  REAL; 

END_ENTITY; 

ENTITY  Process; 

sequence:  LIST  [0:?]  OF  Decision; 

END_ENTITY; 

END  SCHEMA; 
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20.  Express2c++  Generated  Classes 


20.1  processmodel.h 


#ifndef  process_model_h 
#define  process_model_h 


♦include 

♦include 

♦include 

♦include 

♦include 

♦endif 


"Decision . h" 
"Operation . h" 
"Step.h" 

"ListOfDecision . h" 
"Process . h" 


20.2  Decision.h 

♦ifndef  Decision_h 
♦define  Decision_h 

♦include  "rose.h" 

♦define  DecisionOff sets (subclass)  \ 

RoseStructureOff sets (subclass)  \ 
ROSE_SUPERCLASS_OFFSET (subclass.  Decision) 


ROSE_DECLARE  (Decision)  :  virtual  public  RoseStructure  ( 
private : 

STR  PERSISTENT_name; 

STR  PERSISTENT_parent; 

ListOfString  *  PERSISTENT_rules; 

public : 

ROSE_DECLARE__MEMBERS  (Decision)  ; 

/*  Access  and  Update  Methods  */ 

/*  name  Access  Methods  */ 

STR  nameO 

(  return  ROSE_GET_PRIM  (STR, PERSISTENT_name) ; 

) 

Decision  *  name  (STR  aname) 

(  ROSE_PUT_PRIM  (STR,PERSISTENT_name, aname) ; 

return  this; 

) 


/*  parent  Access  Methods  */ 

STR  pa  rent  ( ) 

{  return  ROSE_GET_PRIM  (STR, PERSISTENT_parent) ; 

) 

Decision  *  parent  (STR  aparent) 

(  ROSE_PUT_PRIM  (STR, PERSISTENT_parent, aparenc) ; 

return  this ; 

1 


/*  rules  Access  Methods  */ 

ListOfString  *  rules  (); 

Decision  *  rules  (ListOfString  *  arules) 

(  ROSE_PUT_OBJ  (ListOfString, PERSISTENT_rules, arules) ; 

return  this; 
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/*  Default  Constructor  -  This  constructor  may  be  modified, 
*  but  *DO  NOT*  add  any  calls  that  would  initialize  ROSE. 
*/ 

Decision  ()  ( 

PERSISTENT_name  =  NULL; 

PERSISTENT_parent  =  NULL; 

PERSISTENT_rules  =  NULL; 

1 

Decision  ( 

STR  aname, 

STR  aparent, 

ListOfString  *  arules  ) ; 

}  ; 

#endif 

20.3  Decision.c 

tifndef  Decision_c 
#define  Decision  c 


II  Class  Decision 
#include  "Decision. h" 

ROSE_BEGIN_MEMBERS ( "Decision" , Decision, DecisionOf  f  set s ) 

RO  S  E_S  CH  EMA_NAME ( " p  r o  ce  s  s_mode 1 " ) 
ROSE_VIRTUALSUPERCLASS  (RoseStructure) 

ROSE_VARIABLE (STR, PERSISTENT_name, "name" ) 

ROSE_VARI ABLE  ( STR,  PERS I STENT__pa rent,  "parent") 
ROSE_VARIABLE (ListOfString, PERSISTENT_rules, "rules" ) 
ROSE_END_MEMBERS; 

ListOfString  *  Decision  rules () 

{  if(  ! PERSISTENT_rules) 

if (  this->isPersistent  ( ) ) 

rules  (pnewin  (designO)  ListOfString); 
else  rules  (new  ListOfString) ; 

return  ROSE_GET_OBJ  (ListOfString, PERSISTENT_rules) ; 

1 

/*  Custom  Constructor  */ 

Decision :: Decision  ( 

STR  aname, 

STR  aparent, 

ListOfString  *  arules  ) 

( 

name  (aname) ; 
parent  (aparent) ; 
rules  (arules) ; 

} 

#endi f 

20.4  Operation.h 

#ifndef  Operation_h 
idefine  Operation_h 

tinclude  "rose.h" 

♦include  "Decision. h" 

♦define  OperationOff sets (subclass)  \ 

DecisionOf f sets (subclass)  \ 
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ROSE_SUPERCLASS_OFFSET (subclass, Operation) 


ROSE_DECLARE  (Operation)  :  virtual  public  Decision  { 
private : 

STR  PERSISTENT_op_desc; 
int  PERSISTENT_bid_code; 

public ; 

ROSE_DECLARE_MEMBERS (Operation) ; 

/*  Access  and  Update  Methods  */ 

/*  op_desc  Access  Methods  */ 

STR  op_desc ( ) 

I  return  ROSE_GET_PRIM  (STR, PERSISTENT_op_desc) ; 

) 

Operation  *  op_desc  (STR  aop_desc) 

i  ROSE_PUT_PRIM  (STR, PERSISTENT_op_de3c,  aop_desc) ; 

return  this; 

1 

/*  bid_code  Access  Methods  */ 
int  bid_code() 

i  return  ROSE_GET_PRIM  (int, PERSISTENT_bid_code) ; 

) 

Operation  *  bid_code  (int  abid_code) 

(  ROSE_PUT_PRIM  (int, PERSISTENT_bid_code, abid_code) ; 

return  this; 

) 

/*  Default  Constructor  -  This  constructor  may  be  modified, 

*  but  *DO  NOT*  add  any  calls  that  would  initialize  ROSE. 

*  / 

Operation  ()  ( 

PERSISTENT_op_desc  =  NULL; 

PERSISTENT_bid_code  =  NULL; 

1 

Operation  ( 

STR  aname, 

STR  aparent, 

ListOfString  *  arules, 

STR  aop_desc, 
int  abid_code  ) ; 

)  ; 

#endif 

20.5  Operation.c 

#ifndef  Operation_c 
#define  Operation_c 


/ /  Class  Operation 
#include  "Operation . h" 

ROSE_BEGIN_MEMBERS ( "Operation" , Operation, OperationOf  f set s ) 
RO  S  E_SCHEMA_NAME ( " p  r oce  s  s_mode 1 " ) 
ROSE_VIRTUALSUPERCLASS  (Decision) 

ROSE_VARIABLE (STR, PERS I STENT_op_desc , "op_desc") 
ROSE_VARIABLE ( int , PERSI STENT_bid_code,  "bid_code") 
ROSE  END  MEMBERS; 
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/*  Custom  Constructor  */ 

Operation: :Operation  ( 

STR  aname, 

STR  aparent, 

ListOfString  *  arules, 

STR  aop_desc, 
int  abid_code  ) 
i 

name  (aname) ; 
parent  (aparent) ; 
rules  (arules) ; 
op_desc  (aop_desc) ; 
bid_code  (abid_code) ; 

} 

#endif 

20.6  Step.h 

fifndef  Step_h 
#define  Step_h 

tinclude  "rose.h" 

#include  "Decision. h" 

#define  StepOff sets (subclass)  \ 

DecisionOffsets (subclass)  \ 
ROSE_SUPERCLASS_OFFSET (subClass,  Step) 


ROSE_DECLARE  (Step)  :  virtual  public  Decision  ( 
private ; 

int  PERSISTENT_step_no; 

STR  PERSISTENT_step  desc; 

STR  PERSISTENT_cuttTng_tool; 
int  PERSISTENT_no_passes; 
float  PERSISTENT_step_time; 

public : 

ROSE_DECLARE_.^EMBERS  (Step)  ; 

/*  Access  and  Update  Methods  */ 

/*  step_no  Access  Methods  */ 
int  step_no() 

(  return  ROSE_GET_PRIM  (int, PERSISTENT_step_no) ; 

I 

Step  *  step_no  (int  astep_no) 

(  ROSE_PUT_PRIM  (int, PERSISTENT_step_no, astep_no) ; 

return  this; 

) 


/*  step_desc  Access  Methods  */ 

STR  step_desc() 

I  return  ROSE_GET_PRIM  ( STR, PERSISTENT_step_desc  )  ; 

1 

Step  *  step_desc  (STR  astep_desc) 

{  ROSE_PUT_PRIM  (STR, PERSISTENT_step_desc, astep_desc) ; 

return  this; 

1 

/*  cutting_tool  Access  Methods  */ 

STR  cutting_tool ( ) 

(  return  ROSE_GET_PRIM  (STR, PERSISTENT_cutting_tool ) ; 

1 
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Step  *  cutting_tool  (STR  acutting_tool) 

{  ROSE_PUT_PRIM  (STR, PERSISTENT_cutting_tool, acutting_tool) ; 

return  this; 

} 

/*  no_j)asses  Access  Methods  */ 
int  no_passes() 

(  return  ROSE_GET_PRIM  (int, PERSISTENT_no_passes) ; 

) 

Step  *  no_passes  (int  ano__passes) 

{  ROSE_PUT_PRIM  (int, PERSISTENT_no_passes, ano_passes) ; 

return  this; 

} 

/*  step_time  Access  Methods  */ 
float  step_time() 

(  ret.'rn  ROSE_GET_PRIM  (float, PERSISTENT_step_time) ; 

} 

Step  *  step_time  (float  astep_time) 

{  ROSE_PUT_PRIM  (float, PERSISTENT_step_time, astep_time) ; 

return  this; 

1 

/*  Default  Constructor  -  This  constructor  may  be  modified, 

*  but  *D0  NOT*  add  any  calls  that  would  initialize  ROSE. 

*  / 

Step  0  ( 

PERSISTENT_step_no  =  NULL; 

PERSISTENT_step  desc  =  NULL; 

PERSISTENT_CuttIng_tOOl  =  NULL; 

PERSISTENT_no_passes  =  NULL; 

PERSISTENT_step_time  =  NULL; 

) 

Step  ( 

SIR  aname, 

STR  aparent, 

ListOfString  *  arules, 
int  astep_no, 

STR  astep_desc, 

STR  acutting_tool, 
int  ano_passes, 
float  astep_time  ); 

1  ; 


fendif 

20.7 

Step.c 

#ifndef 

Step_c 

♦define 

Step_c 

//  Class  Step 
#include  "Step.h" 

ROSE_BEGIN_MEMBERS ( "Step" , Step, StepOf fsets) 
ROSE_SCHEMA_NAME{"proces  S_mode 1 " ) 

ROSE_VIRTUALSUPERCLASS  (Decision) 

ROSE_VARIABLE  ( int ,  PERS I STENT_step_no,  "step_r.o"  ) 
ROSE_VARIABLE (STR, PERSI STENT_step_desc , "step_desc" ) 
ROSE_VARIABLE (STR, PERSI STENT_cutt ing_tool , " cut t i oq_t ool " ) 
ROSE_VARIABLE (int , PERSISTENT_no_passes, "no_passes" ; 
ROSE_VARIABLE (float , PERS I STENT_step_t ime , " step_t ime" ) 

ROSE  END  MEMBERS; 
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/*  Custom  Constructor  */ 

Step: : Step  { 

STR  aname, 

STR  aparent, 

ListOfString  *  arules, 
int  astep_no, 

STR  astep_desc, 

STR  acutting_tool, 
int  ano_pa33es, 
float  astep_time  ) 
i 

name  (aname) ; 
parent  (aparent) ; 
rules  (arules); 
step_no  (a3tep_no) ; 
step_desc  (astep_desc) ; 
cutting_tool  (acutting_tool ) ; 
no_passes  (ano_passes)  ; 
step_time  (astep_time) ; 

} 

#endif 

20.8  ListOfDecision.h 

lifndef  ListOfDecision_h 
#define  ListOfDecision  h 


//  Class  ListOfDecision 
#include  "rose.h" 

ROSE_DECLARE  (Decision) ; 
declare (List , Decision)  ; 

#endif 

20.9  ListOfDecision.c 

#ifndef  ListOfDecision_c 
#define  ListOf Decision_c 

♦include  "ListOfDecision.h" 

implement2 (List , Decision, "process_model") ; 
#endi f 


20.10  Process.h 

♦ifndef  Process_h 
♦define  Process_h 

♦include  "rose.h" 

ROSE_DECLARE  (ListOfDecision) ; 

♦define  ProcessOffsets (subclass)  \ 

RoseStructureOff sets (subclass)  \ 
ROSE_SUPERCLASS_OFFSET ( subclass , Process ) 


ROSE_DECLARE  (Process)  :  virtual  public  RoseStructure  ( 
private : 
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ListOfDecision  *  PERSISTENT_sequence; 
public : 

ROSE_DECLARE_MEMBERS (Process) ; 

/*  Access  and  Update  Methods  */ 

/*  sequence  Access  Methods  */ 

ListOfDecision  *  sequence (); 

Process  *  sequence  (ListOfDecision  *  asequence) 

{  ROSE_PUT_OBJ  (ListOfDecision, PERSISTENT_sequence, asequence) ; 

return  this; 

) 

/*  Default  Constructor  -  This  constructor  may  be  modified, 

*  but  *DO  NOT*  add  any  calls  that  would  initialize  ROSE. 

*/ 

Process  ()  { 

PERSISTENT_sequence  =  NULL; 

) 


Process  ( 

ListOfDecision  *  asequence  ) ; 

)  ; 

#endif 


20.11  .c 

#ifndef  uess_c 

#define  Process  c 


II  Class  Process 
*  include  "Process. h" 

#include  "ListOfDecision , h" 

ROSE_BEGIN_MEMBERS ( "Process", Process, ProcessOf f sets ) 

RO  S  E_S  C  H  EMA_NAME ("process _mode 1 " ) 

ROSE_VIRTUALSUPERCLASS  (RoseStructure) 

ROSE_VARIABLE (ListOfDecision, PERSISTENT_sequence, "sequence" ) 
ROSE_END_MEMBERS ; 

ListOfDecision  *  Process  sequence () 

(  if(  !PERSISTENT_sequence) 

if(  this->isPersistent  ( ) ) 

sequence  (pnewin  (designO)  ListOfDecision); 
else  sequence  (new  ListOfDecision)  ; 

return  ROSE_GET_OBJ  (ListOfDecision, PERSISTENT_sequence) ; 

) 


/*  Custom  Constructor  */ 

Process :: Process  ( 

ListOfDecision  *  asequence  ) 

sequence  (asequence) ; 


#endi f 
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30.  Compiled  Process  Model  Schema 


Format  =  "rose_r3.0" 

ROSE_OIDS  ( 

(0  =  0x0000000000000000000000000000000000000000) 
(1  =  Ox007D210704000029B6822F00001C7e0300000000) 

) 


ROSE_DESIGN  (RoseDesign 

name:  "proces3_model" 
root :  $ 


keyword_table :  $ 
name_table:  <1-1> 

schemas:  (<l-30>  ListOf RoseDesign 
<")ceystone3_0  ">) 


STEP_OBJECTS  ( 

(<1-1>  DictionaryOf RoseOb ject 

listOfKeys:  (<l-2>  ListOfSTR 
"Decision" 

"Operation" 

"Step" 

"Process" 

"ListOf Decision") 

listOfValues :  (<l-3>  ListOf RoseOb ject 

(<l-0>  RoseDomain 

name:  "Decision" 

listOfSuper:  (<l-8>  ListOf RoseDomain 
<")ceystone3_0"  0-600>) 
listOfAttribute :  i<l-9>  ListOf RoseAttribute 
(<1-10>  RoseAttribute 
name:  "name" 

domain:  <")<eystone3_0"  0-4>) 
RoseAttribute 
name:  "parent" 

domain:  <")ceystone3_0 "  0-4>) 
(<1-12>  RoseAttribute 
name:  "rules" 

domain:  <")ceystone3_0"  0-1180>))) 

(<l-4>  RoseDomain 

name:  "Operation" 

listOfSuper:  (<1-13>  ListOf RoseDomain 
<l-0>) 

listOfAttribute:  (<1-14>  ListOf RoseAttribute 
(<1-15>  RoseAttribute 
name:  "op_desc" 
domain;  <")ceystone3_0"  0-4>) 
(<1-16>  RoseAttribute 
name:  "bid_code" 
domain:  <" keystone3_0 "  0-l>) ) ) 

(<l-5>  RoseDomain 
name:  "Step" 

listOfSuper:  (<1-17>  ListOf RoseDomain 
<l-0>) 

listOfAttribute:  (<1-18>  ListOfRoseAttribute 
(<1-19>  RoseAttribute 
name:  "step_no” 
domain;  <"keystone3_0"  0-l>) 
(<l-20>  RoseAttribute 

name:  "step_desc" 

domain;  <"keystone3_0"  0-4>) 
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<<1-21>  RoseAttribute 

name:  "cutting_tool " 
domain:  <"keystone3_0"  0-4>) 

(<l-22>  RoseAttribute 

name:  "no_passes" 

domain:  <")ceystone3_0"  0-l>) 

(<l-23>  RoseAttribute 

name:  "step_time" 

domain:  <"keystone3_0"  0-2>) ) ) 

(<l-6>  RoseDomain 

name:  "Process" 

listOfSuper;  (<l-24>  ListOf RoseDomain 
<"keystone3_0"  0-600>) 

listOfAttribute :  (<l-25>  Li stOf RoseAtt ribute 

(<l-26>  RoseAttribute 
name:  "sequence" 
domain:  (<l-7>  RoseDomain 
name:  "ListOfDecision" 
listOfSuper:  (<l-27>  ListOf RoseDomain 
<"keystone3_0"  0-1102>) 
listOfAttribute:  {<l-28>  ListOf RoseAttribute 
(<l-29>  RoseAttribute 

name:  "Decision" 
domain :  <l-0>) ) ) ) ) ) 


<l-7>) ) 
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40.  C++  Program  -  Instantiates  Process  Model  Objects 
from  ASCII  Process  Data  File 

/*  Include  headers  for  ROSE  Library  and  program  classes  */ 
tinclude  <stdio.h> 
tinclude  <string.h> 

#include  <ctype.h> 

#include  <fcntl.h> 

# include  "rose.h" 

# include  "process_model . h" 

# define  MAXLINE  81 
#define  MAXBUF  256 

void  strip_trailing_blanks (char  * ) ; 

main  ( ) 

( 

char  a_fn [MAXLINE] ; 

char  buff [MAXBUF] ; 

FILE  *inp; 

ListOfString  *  1 rules ; 

float  f 1; 

int  num_rules,  x; 


printfC  ENTER  INPUT  ASCII  DATA  FILENAME:  "); 
scanf ("%s", a_f n) ; 

/***  Open  Input  ASCII  Process  Data  File  ***/ 
if  ( (inp  =  fopen(a_fn,  "r") )  ==  (FILE  *)  NULL) 

{ 

printf ( "ERROR  opening  %s  DATA  FILE\n",  a_fn) ; 
exit  (1 ) ; 

1 

/***  Create  a  rose  database  to  store  process_model  type  objects  ***/ 

ROSE . newDesign  ("process_data") ; 

ListOfDecision  *xyz  =  pnew  ListOfDecision; 

wnile  (fgets(buff,  MAXBUF,  inp)  !=  NULL) 

f 

pr int f ( " ' %s ' " ,  buff); 

if  (strncmp (buf f ,  1)  ==  0)  /*  comment  */ 

continue; 

else  if  (strncmp (buf f,  "Decision",  8)  ==  0)  /*  Decision  Is  Being  Added  */ 

f 

printf ("Inside  Decision\n\n" )  ; 

/***  Create  Decision  Objects  in  the  database  ***/ 

Decision  *dl  =  pnew  Decision; 

if  ( f gets (buf f , MAXBUF, inp)  !=  NULL) 

( 

strip_trailing_blan)cs  (buff)  ; 
printf  ("' %s ,  buff ) ; 
dl->name (buff) ; 

} 

if  (fgets (buff , MAXBUF, inp)  !=NULL) 
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( 

strip_trailing_blank;s  (buff)  ; 
printf (" ' %s ' buff); 
dl->parent (buff)  ; 


Irules  =  pnew  ListOfString; 

if  ( f gets (buff ,MAXBUF,inp)  !=NULL) 

{ 

strip_trailing_blan)cs  (buff)  ; 
printf ("' %3 ' buff); 
sscanf(buff,  "%d",  &num_rules) ; 

) 

for  (int  i=0;  i<num_rule3;  i++) 

( 

if  (fgets (buff,MAXBUF,inp)  !=NULL) 

{ 

strip_trailing_blan)c3  (buff)  ; 
printf  ("' %s  '  buf f ) ; 
lrules->add (buf f ) ; 

) 

} 

dl->rules (Irules) ; 
xy z->add (dl ) ; 


else  if  (strncmp (buf f ,  "Operation",  9)  ==  0)  /*  Operation  Is  Being  Added  * / 
( 

printf ("Inside  Operation\n\n") ; 

/***  Create  Operation  Objects  in  the  database  ***/ 

Operation  *operl  =  pnew  Operation; 

if  (fgets  (buff, MAXBUF,inp)  .'=  NULL) 

{ 

strip_trailing_blanks (buff)  ; 
printf ("' %s ' buff); 
operl->name (buff)  ; 

} 

if  (fgets (buff ,MAXBUF,inp)  !=  NULL) 

{ 

strip_trailing_blanks (buff)  ; 
printf ("'%s'",  buff); 
operl->parent (buff)  ; 

} 

Irules  =  pnew  ListOfString; 
if  (fgets (buff ,MAXBUF, inp)  !=  NULL) 

{ 

strip_trailing_blank3 (buff) ; 

printf ("' %s ' ",  buff); 

sscanf  (buff,  "%d",  &num__rules)  ; 

1 

for  (int  i=0;  i<num_rules;  i++) 

{ 

if  (fgets (buff ,MAXBUF, inp)  !=NULL) 

{ 

strip_trailing_blanks (buff)  ; 
printf ("'%s'",  buff); 

Irul es->add (buff) ; 

1 

) 

operl->rules (Irules) ; 

if  (fgets (buff, MAXBUF, inp)  !=NULL) 
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( 

strip_trailing_blanks (buff) ; 
printf buff); 
operl->op_de3C (buff)  ; 

) 

if  (fgets (buff jMAXBUF, inp)  !=  NULL) 

{ 

strip_trailing_blanks (buff) ; 
printf (”' %3 ' buff ) ; 
sscanf  (buff ,  "%ci",  &x)  ; 
operl->bid_code (x) ; 

} 

xyz->add (operl)  ; 


Ise  /*  Step  Is  Being  Added  */ 
printf ("Inside  Step\n\n"); 

/***  Create  Step  Objects  in  the  database  ***/ 
Step  *stepl  =  pnew  Step; 

if  (fgets (buff,MAXBUF,inp)  !=  NULL) 

strip_trailing_blanks (buff) ; 
printf ("'%s'",  buff); 
stepl->name (buff) ; 

1 

if  (fgets (buff, MAXBUF,inp)  !=  NULL) 

{ 

3trip_trailing_blanks (buff)  ; 
printf ("' %s buff); 
stepl->parent (buff)  ; 

} 

Irules  =  pnew  ListOf String; 
if  (fgets (buff, MAXBUF,inp)  !=NULL) 

( 

strip_trailing_blanks (buff)  ; 

printf {"'%s'",  buff); 

sscanf (buff,  "%d",  &num_rules) ; 

} 

for  (int  i=0;  i<num_rules;  i++) 

if  (fgets (buff, MAXBUF,inp)  !=  NULL) 

( 

strip_trailing_blanks (buff) ; 
printf ("' %s ' buff); 
lrules->add(buf f ) ; 

) 

) 

stepl->rule3 (Irules) ; 

if  (fgets (buff ,MAXBUF,inp)  !=NULL) 

{ 

strip_trailing_blanks (buff) ; 
printf ("' %s ' ",  buff )  ; 
sscanf (buff ,  "%d",  ix)  ; 
stepl->3tep_no (x)  ; 

) 

if  (fgets (buff ,MAXBUF, inp)  !=NULL) 

( 

strip_trailing_blanks (buff)  ; 
printf ("'%s'",  buff); 
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stepl->3tep_desc (buff)  ; 

} 

if  (fgets (buff,MAXBUF,inp)  !=  NULL) 

( 

3trip_trailing_blan)c3  (buff) ; 
printf  (" ' %3 ' buff ) ; 
stepl->cutting_tool (buff) ; 

) 

if  (fgets (buff ,MAXBUF, inp)  !=  NULL) 

{ 

strip_trailing_blan)c3  (buff) ; 
printf ("' %s ' buff); 
sscanf(buff,  "%d",  &x) ; 

3tepl->no_pa33es (x) ; 

} 

if  (fgets (buff, MAXBUF, inp)  !=  NULL) 

( 

strip_trailing_blan)cs  (buff) ; 
printf  ("' %3  '  ",  buff); 
sscanf (buff ,  "%f",  &fl) ; 
stepl->step_time  (f 1) ; 

) 

xyz->add (stepl ) ; 

} 

}  /*  end  of  while  fgets  */ 

/***  Display  all  STEP  Objects  in  the  process  data  model  ***/ 
ROSE . display ( ) ; 

/***  Save  the  process  data  model  ***/ 

ROSE . saveDesign ( ) ; 

f close (inp) ; 


/***  Strips  trailing  blan)(s  ***/ 

void  strip_trailing_blan)QS  (char  *string) 

( 

int  len,  )c; 

len  =  strlen (string) ;  /*  calculate  length  of  string  */ 

string[len-l]  =  '\0';  /*  delete  newline  character  from  end  of  line  */ 

/*  get  ride  of  trailing  blan)cs  */ 
for  (k=len-2;  k>0;)c — ) 

{ 

if  (string[k]  ==  '  ') 
string [k]  =  ' \0 ' ; 
else  break; 


} 
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50.  Input  ASCII  Process  Data  File 

Decision 

Panel/Chassis 

NULL 

3 

ALUM 

STEEL 

CRES 

# 

Decision 

Sheet 

Panel/Chassis 

1 

part_qty  <  1000 
# 

Operation 

Shear 

Sheet 

2 

1  hole 

hole_qty  <  8 
Shear  to  Size 
30 
# 

Decision 

Punch 

Sheet 

2 

single_d 

double_ci 

# 

Operation 

Single  Station  Punch  Press 
Punch 
1 

part_qty  <  25 

Perform  manual  punching  operation 

35 

# 

Operation 
CNC  Punch 
Punch 
1 

part  qty  >=  25 

Perform  CNC  punching  operation 
40 
# 

Operation 

Holemaking 

Sheet 

3 

single_diam 

counterbore 

countersunk 

Holemaking  in  the  flat 

30 

# 

Step 

Ream 

Holemaking 

1 

always  pick 
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1 

ream  hole 
ream_tool 

T 

i. 

0.25 

# 

Step 

Bore 

Holemaking 

1 

counterbore 

2 

bore  hole 
bore_tool 
1 

0 .15 
# 

Step 

Drill 

Holemaking 

1 

always  pick 
3 

drill  hole 
drill_tool 
3 

0.45 

# 

Operation 

TimeSaver 

Sheet 

1 

always  pick 

Time  Saving  Operation  in  the  flat 

30 

# 

Decision 

Strip 

Panel/Chassis 

1 

part_qty  >=  1000 
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60.  Instantiated  Process  Model  ROSE  Output  Database 

Format  =  "rose_r3.0" 

ROSE_OIDS  ( 

(0  =  OxOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOC) 

(1  =  Ox007D210704000029B6836500001CE60200000000) 


ROSE_DESIGN  (RoseDeaign 

name:  ”process_data" 
root :  $ 

)ceyword_table :  $ 
name_table:  $ 

schemas:  (<l-25>  ListOfRoseDesign 
<"keystone3_0"> 
<"process_model">) 


STEP_OBJECTS  { 

(<l-0>  ListOfDecision 
(<1-1>  Decision 

name:  "Panel/Chassis” 
parent:  "NULL” 
rules:  (<l-2>  ListOfSTR 
"ALUM" 

"STEEL" 

"CRES") ) 

(<l-3>  Decision 

name:  "Sheet" 
parent:  "Panel/Chassis” 
rules:  {<l-4>  ListOfSTR 
"part_qty  <  1000")) 

(<l-5>  Operation 

name:  "Shear" 
parent:  "Sheet" 
rules:  (<l-6>  ListOfSTR 
" !hole" 

"hole_qty  <  8") 
op_desc:  "Shear  to  Size" 
bid_code:  30) 

(<l-7>  Decision 

name:  "Punch" 
parent:  "Sheet" 
rules:  (<l-8>  ListOfSTR 
"single_d" 

"double_d") ) 

(<l-9>  Operation 

name:  "Single  Station  Punch  Press" 
parent:  "Punch" 
rules:  (<1-10>  ListOfSTR 
"part_qty  <  25") 

op_desc:  "Perform  manual  punching  operation" 
bid_code:  35) 

(<1-11>  Operation 

name:  "CNC  Punch" 
parent:  "Punch" 
rules:  (<1-12>  ListOfSTR 
"part_qty  >=  25") 

op_desc:  "Perform  CNC  punching  operation" 
bid_code:  40) 

(<1-13>  Operation 

name:  "Holemaking" 
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parent:  "Sheet" 
rules:  (<1-14>  OfSTR 

"3ingle_c:i  *ti  ‘ 

"counterbore" 

"countersunk" ) 

op_desc:  "Holeitiaking  in  the  flat" 
bid_code:  30) 

(<1-15>  Step 

name:  "Ream" 
parent:  "Holemaking" 
rules:  (<1-16>  ListOfSTR 
"always  pick") 
step_no;  1 

step_desc:  "ream  hole" 
cutting_tool :  "ream_tool" 
no_passes:  2 
step_time:  0.25) 

(<1-17>  Step 

name:  "Bore" 
parent:  "Holemaking" 
rules:  (<1-18>  ListOfSTR 
"counterbore") 
step_no:  2 

step_desc:  "bore  hole" 
cutting_tool :  "bore_tool" 
no_passes:  1 
step_time:  0.15) 

(<1-19>  Step 

name:  "Drill" 
parent:  "Holemaking" 
rules:  (<l-20>  ListOfSTR 
"always  pick") 
step_no;  3 

step_desc:  "drill  hole" 
cutting_tool :  "drill_tool" 
no_pas3es:  3 
step_time:  0.45) 

(<1-21>  Operation 

name:  "TimeSaver" 
parent:  "Sheet" 
rules:  (<l-22>  ListOfSTR 
"always  pick") 

op_desc:  "Time  Saving  Operation  in  the  flat" 
bid_code:  30) 

(<l-23>  Decision 

name;  "Strip" 

parent:  "Panel/Chassis" 

rules;  (<l-24>  ListOfSTR 

"part_qty  >=  1000"))) 
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** 


70.  C++  Program  -  Selects  Two  Process  Plan  Sequences 

/»  Include  headers  for  ROSE  Library  and  program  classes  */ 
finclude  <stdio.h> 

♦include  "rose.h" 

♦include  "process_model . h" 


main  ( ) 

{ 

int  X  =  0; 
int  xl  =  0; 

ListOfDecision  dList; 

/*»*  Read  in  the  Process  Data  File  ***/ 

ROSE . useDesign ( "process_data" ) ; 

ROSE . f indOb jects  (idList); 

ROSE . newDesign ("selected")  ; 

int  n  =  dList . size ()  ; 
printfC'N  =  %d\n",  n)  ; 

Process  *pl  =  pnew  Process; 

ListOfDecision  *nllist  =  pnew  ListOfDecision; 

for  (int  i=0;  i<  n;  i++) 
i 

printfC'Name  is  '%s'\n",  dList  [i) ->name  ())  ; 
if  (strcmp (dList [i] ->name () ,  "Holemaking" )  ==  0) 

{ 

X++; 

nllist->add (dList [i] ) ; 

) 

else  if  (strcmp (dList ti] ->name 0 ,  "Ream")  ==  0) 

( 

X++  ; 

nllist->add (dList [i] ) ; 

) 

else  if  (strcmp (dList [i] ->name () ,  "Bore")  ==  0) 

( 

X++; 

nllist->add (dList [i] ) ; 

} 

else  if  (strcmp (dList [i ] ->name () ,  "Drill")  ==  0) 
i 

X  +  +  ; 

nllist->add(dList [i] ) ; 

} 

pl->3equence (nllist) ; 


Process  *p2  =  pnew  Process; 

ListOfDecision  *n21ist  *=  pnew  ListOfDecision; 

for  (i=0;  i<  n;  i++) 

I 

printfC'Name  is  '%s'\n",  dList  [  i ) ->name  ())  ; 
if  (strcmp (dList [i] ->name () ,  "Punch")  ==  0) 
I 

xl  +  +  ; 
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n21ist->add (dList [i ] ) ; 

} 

else  if  (strong (dList [i] ->name () ,  "Single  Station  Punch  Press")  ==  0 
{ 

xl  +  +; 

n21i3t->add (dList [i] ) ; 

) 

else  if  (strcnp (dList [i] ->name () ,  "CNC  Punch")  ==  0) 

{ 

xl++  ; 

n21ist->add (dList [i] ) ; 

) 

p2->sequence (n21ist) ; 


/***  Save  the  selected  process  **»/ 

ROSE . saveDesign ( ) ; 

ROSE . display  ( ) ; 

for  (i=0;  i  <  x;  i++) 

printf ("NlList  is  '%s'\n",  (*nllist ) I i ] ->name ( ) ) ; 
for  (i=0;  i  <  xl;  i++) 

printf ( "N2List  is  '%s'\n",  (*n21ist) [i] ->name ( ) ) ; 
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80.  Output  ROSE  Database  Containing  Two  Process 
Plans 


Format  =  "rose_r3.0" 

ROSE_OIDS  ( 

(1  =  0x0000000000000000000000000000000000000000) 
(2  =  Ox007D210704000029B685B200001D610200000000) 
(0  ■=  Ox007D210704000029B6836500001CE60200000000) 

) 

ROSE_DESIGN  (RoseDesign 
name:  "selected" 
root :  $ 

)teyword_table :  $ 
name_table:  $ 

schemas:  (<2-4>  ListOf RoseDesign 
<"process_model"> 

<")ceystone3_0">) 

) 

STEP_OBJECTS  ( 

(<2-0>  Process 

sequence:  (<2-l>  ListOfDecision 
<"proce3S_data"  0-13> 
<"process_data"  0-1 5> 
<"process_data"  0-17> 
<"process_data"  0-19>) ) 

(<2-2>  Process 

sequence:  (<2-3>  ListOfDecision 
<"process_data"  0-7> 

<"process_data"  0-9> 

<"process_data"  0-ll>) ) 
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90.  C++  Program  -  Read  In  Process  Plans  ROSE 
Database 

/*  Include  headers  for  ROSE  Library  and  program  classes  */ 
#include  <stdio.h> 

#include  "rose.h" 

# include  "process_model . h" 

declare (List, Process) ; 
implement (List,  Process)  ; 

main  ( ) 

{ 

int  X  =  0; 
int  xl  =  0; 

ListOf Process  dList; 

ListOfDecision  *seq; 

/***  Read  in  the  Process  Data  File  ***/ 

ROSE. useDesign ("selected") ; 

ROSE . f indOb jects  (SdList) ; 

int  n  =  dList . size  0 ; 
printfC'N  =  %d\n",  n)  ; 

for  (int  i=0;  i<  n;  i++) 

( 

seq  =  dList [i] ->sequence () ; 

for  (int  j=0;  j<  seq->sizeO;  j++) 

printf ("Proces3%d  -  %s\n",  i+1,  (*seq) [ j ] ->name ( ) ) ; 

1 

ROSE . display ( ) ; 


Distribution  List 


DPRO-Raytheon 

C/0  Raytheon  Company 

Spencer  Lab..  Wayside  Ave. 

(one  copy) 

Defense  Advanced  Research  Projects  Agency 

ATTN:  Defense  Sciences  Office;  Dr.  H.  Lee  Buchanan 

Virginia  Square  Haza 

3701  N.  Fairfax  Drive 

Arlington.  VA.  22203-1714 

(one  copy) 

Defense  Advanced  Research  Projects  Agency 

ATTN:  Electronic  Systems  Technology  Office;  Capt.  Nicholas  J.  Niclerio,  USAF 

Virginia  Square  Plaza 

3701  N.  Fairfax  Drive 

Arlington.  VA.  22203-1714 

(one  copy) 

Defense  Advanced  Research  Projects  Agency 

ATTN:  Contracts  Management  Office;  Mr.  Donald  C.  Sharkus 

Virginia  Square  Haza 

3701  N.  Fairfax  Drive 

Arlington,  VA.  22203-1714 

(one  copy) 

Defense  Technical  Information  Center 
Building  5,  Cameron  Station 
ATTN:  Selections 
Alexandria,  VA  22304 
(two  copies) 


